1. Field
The present invention relates generally to computer systems and more particularly microprocessor based computer systems.
2. Background Information
System management mode (SMM) allows systems developers to provide low-level functions, such as power management or security, in a manner that is transparent to operating systems and application programs. SMM allows operating system and application software operation to be interrupted to perform these low level functions. After performing the low level function, the operating system or application software operation is resumed from the point that it was interrupted.
In order to initiate a low level function, a hardware interrupt, referred to herein as the System Management Interrupt (SMI), is generated. When an SMI is received, the processor waits for all pending writes to complete. The processor also waits for writes pending on external devices, such as external caches. Once all pending writes are completed, the processor then saves some of its current execution state to System Management Random Access Memory (SMRAM) and begins execution of the SMM handler, a software routine that performs low level functions, such as error reporting and logging, I/O emulation, suspend or resume operation, and power management.
SMRAM is memory that is reserved for SMM. The SMM handler is stored in SMRAM. Before execution of the SMM handler, the processor automatically stores some of its current execution state in a reserved portion of SMRAM. For example, the processor often stores the state of its segmentation registers, general-purpose registers, instruction pointer, descriptor table registers, and model specific registers in the reserved portion of the SMRAM. Some register state, such as the floating-point registers, may not be automatically stored upon entry to SMM since many SMM handlers do not modify these registers. However, if these registers are used in an SMM handler, code to store and restore these registers may be included in the SMM handler routine.
SMM handler codes for platforms are written using a compatible SMRAM region that typically resides below one-megabyte of memory. The compatible SMRAM region and video memory share use of A-B memory segments. Due to sharing of A-B memory segments between two different agents dependent on executing in SMM mode, the compatible SMRAM typically runs in an un-cached environment. Due to the latency of code execution being large in an un-cached environment, the SMM handler code is migrated to another memory region to take advantage of the cached environment that is provided through an extended SMRAM region of system memory.
SMM software can run in two modesxe2x80x94below one-megabyte and above one-megabyte. The SMRAM region that resides below one-megabyte is commonly referred to as xe2x80x9cCompatiblexe2x80x9d SMRAM and the SMRAM region that resides above one-megabyte is commonly referred to as xe2x80x9cExtendedxe2x80x9d SMRAM. Because the extended SMRAM handler executes above the one-megabyte boundary, code within the extended SMRAM handler executes in protected mode. However, it is typically easier to invoke real-mode interrupts when executing a compatible SMRAM handler that runs below one-megabyte. In particular, SMM handlers usually require execution ability below the one-megabyte memory boundary in order to execute system BIOS calls (e.g., plug-and-play, APM, INT13h power-down/power-up hard drives) and graphics BIOS calls (e.g., monitor ON/OFF calls, panel blanking, CRT rotations, graphics suspend save/restore, etc.).
What is needed therefore is a method and apparatus for executing real-mode interrupts in an extended SMRAM environment.